loongarch: Add basic support for LoongArch32 #1837
Conversation
| /// Calculate the approximate double-precision result of dividing 1.0 by the square root | ||
| #[inline] | ||
| #[target_feature(enable = "frecipe")] | ||
| #[unstable(feature = "stdarch_loongarch", issue = "117427")] | ||
| pub unsafe fn frsqrte_d(a: f64) -> f64 { | ||
| __frsqrte_d(a) | ||
| } |
There was a problem hiding this comment.
looks like llvm will just optimize this (no target feature is even needed): https://godbolt.org/z/5s6hvKE51.
Overall we prefer to have fewer (manual) extern "unadjusted¨ items. Also you should probably add some tests that these instructions actually produce the instructions you expect, like so
#[cfg_attr(all(test, target_feature = "frecipe"), assert_instr(frsqrt.d))]assuming that frecipe is enabled on CI.
There was a problem hiding this comment.
looks like llvm will just optimize this (no target feature is even needed): https://godbolt.org/z/5s6hvKE51.
They're different -- frsqrte_d_manual generates frsqrt.d, not frsqrt**e**.d.
Overall we prefer to have fewer (manual)
extern "unadjusted¨items. Also you should probably add some tests that these instructions actually produce the instructions you expect, like so#[cfg_attr(all(test, target_feature = "frecipe"), assert_instr(frsqrt.d))]assuming that
frecipeis enabled on CI.
Sure, I'll add more test cases. Perhaps in a separate PR to keep things focused. Thanks!
There was a problem hiding this comment.
ah, my bad. so the "e" is for "estimate" apparently. Maybe use that word? (most functions on floats approximate the answer, but apparently this intrinsic deliberately uses less precision to achieve higher speed).
No description provided.